Swift Playgrounds – Learn to code on your iPad
apple.com
apple.com
Semi warranted. But I teach swift to teenagers, and have set up hundreds of devices/machines with Xcode/etc at this point. Yes, it's still prone to random bugs, like most software, but with sideloading it's getting pretty darn close to plug in your phone, press Run, and It Just Works.
Even if that's true, you're still locked into Apple's world—a privilege you paid for.
If I'm snarky it's because calling this "revolutionary" is a slap in the face to the people who've spent their careers working to understand early education through computers, without the ulterior motive of said platform lock-in.
Development tools should be open, at least we should be able to target platforms generically.
Even the original Mac still had fairly comprehensive documentation of parts of its hardware, if you bought the phone book edition of Inside Macintosh.
And of course, IBM didn't 'settle' for opening up the platform. Compaq and Phoenix Technologies opened it for them.
Apple was the last surviving company of home computers, from the likes of Acorn, Atari, Commodore, MSX,.....
All of them controlled the whole experience, both hardware and software.
By the time Apple bought NeXT (which in practice was actually the other way around), they need to attract developers back to their platform, so they played nice.
Nowadays they have plenty of money on the bank and can be back to being as they always were.
"Spectravideo, Philips, Al Alamiah, Sony, Sanyo, Mitsubishi, Toshiba, Hitachi, National, Panasonic, Canon, Casio, Pioneer, Fujitsu General, Yamaha, JVC, Yashica-Kyocera, GoldStar, Samsung/Fenner, Daewoo/Yeno, Gradiente, Sharp/Epcom, Talent, Frael."
AGE Labs
Then come back and tell me that they are "open".
Bitcode sounded so good back when it came out, but is actually a way of guaranteeing that people only use Apple tools for shipping software.
C++ surely does unless you don't use Apple's compiler, as for the others they are in the process of making it happen.
> And once they do, the managed runtimes will be slow as molasses.
I guess you mean as fast as the Objective-C and Swift managed runtimes.
- Explicit instrumentation for null pointer checks (slow)
- Explicit instrumentation for stack overflow checks (slow)
- Explicit instrumentation for GC safe points (slow)
- Exceptions and unwinding implemented on top of cxx_throw instead of signals and setjmp/lonjmp (slow and error prone)
- Defensively generated trampolines for reflection for any thinkable parameter type permutation
There are quite a few more details that make managed runtimes under bitcode suboptimal.
Taking away things like read/write register access, signals and system APIs like setjmp/longjmp puts managed runtimes at a huge disadvatage.
Neither Swift nor ObjC (and to a large degree C++) need to solve any of these problems.
There is also room for the AOT bitcode optimizations to hoist many of those checks, specially since the AOT compilation takes place at the store side with lots of resources available.
Android and Windows Phone have already proven that those issues aren't an actual issue from the user point of view, specially on the Android side if you take into account the market share.
Android and Windows Phone don't lock their respective managed runtimes down like Apple does lock down the likes of Mono/Xamarin. On Android you have full access to almost everything, and on Windows Phone MS has a vested interest in exposing all required features to their managed runtime. No such luck on Apple hardware.
Apple 8 bit computers weren't even relevant in Europe.
Yet I managed to learn pretty well.
Even if you write for Windows, you'll be using APIs that only work on there (eg if you write in C++ using MFC or COM, or write using .NET and eg. find that you can only do certain things with Invoke by calling into system DLLs, which you won't be able to do on other platforms, despite the open source nature of .NET these days).
If you write for iPad, you are restricted to their iOS APIs.
If you write for Mac OS, you'll be restricted to there, as you use Cocoa.
If you write for Android, you'll be restricted to there, as you write using Android's APIs despite the existence of Java and some of its runtime. You could attempt C++ on here but the NDK is a bolt-on.
The only true solution seems to be to write in a language that is available across all platforms (C++?) using a library that works across all of them (doesn't exist), but this is non-existent as the ways the systems behave (windowing, application process cycle) is different on each platform and it would be foolish to believe that they should be the same, or that they behave in the same way.
I think we should just accept that each platform has its merits and disadvantages and stop aiming for this dream of easy cross-compatibility with little developer effort. On all platforms we have to buy the hardware, sometimes have to buy the tooling, and then have to submit our applications to the respective markets or distribution channels (even on Linux, we can't just chuck our stuff at repos, particularly if we want to sell it). Ultimately if we write for a platform, there will always be lock-in of some sort (eg why can't I run my EXE on Mac?).
I like how the URL includes "basics" which indicates my knowledge (or lack thereof).
Thanks for the link, I have reading to do
If Apple doesn't fail, then those people need to have a long hard look at their careers.
I still think it's a good thing, just that it brings a different perspective to the "walled-garden" argument against many brands/services as well as tech education as a whole.
The goal is not to make them the developers of tomorrow - just to expose them to programming, and light CS thinking. They don't get these opportunities at school. If they don't like it, well hey at least they tried. If they like it, then great! They have discovered a new passion they might have not found otherwise. We've been doing this for a few years now, and many of them (about 40%) have gone on to study CS or something related in college; of those, a fair number also got the motivation to go to college partly because it'd allow them to study CS.
We very much emphasize the fact during the workshop that if they understand the basics (variables, loops, functions, etc.) then they can learn any language. A big part of the pedagogy is encouraging them to try things, fail, use Stack Overflow, etc.
Gender split is basically 50/50, a fair mix of black/hispanic/asian kids with the few white kids sprinkled in.
All that said, a fair amount of them do have iPhones.
It looks simple but it's actually about 6 different programs all stuck together.
Codesigning breaks on it periodically, and it takes days to fix.
XCode 8 has just broken this worse than any other XCode version in history. It seems to have done so by trying to automate all its requirements. So now it outputs broken bundles when I compile it. This has taken me all of today, and I'll be surprised if I have it working within the next 6 hours of work.
This is a fairly typical experience of using XCode for me. Many times getting codesigning working correctly and getting it working within the mac app store parameters takes more time than writing the code.
In short: Using XCode is harder than programming.
(Where nobody can create anything.)
Sure, some people don't like onscreen keyboards and such, but everybody has their preferences and comfort zones especially when it comes to creative activities. It's a very personal activity. But at this stage unequivocally saying mobile devices are not good for creating is just plain flat out provably false.
I've long been of the opinion based on what I've seen and personally found that mobile (including also most tablets) is basically worthless for anything but consumption and casual communication, with a comment or photo being the limit of their creative potential. If I want to really make something I want more I/O bandwidth and a "real OS" where my data can be mine.
Even less charitably I've seen the whole platform as one big dark pattern designed to turn users into passive consumers that can be transparently surveiled.
Procreate http://procreate.si/
PINNACLE STUDIO PRO http://www.pinnaclesys.com/PublicSite/us/Products/studio/ipa...
Continuous http://continuous.codes/
Coda https://panic.com/coda-ios/
Adobe Sketchbook Pro https://www.sketchbook.com/?locale=en
iMovie
Swift Playgrounds (has full access to iOS libs) http://www.apple.com/swift/playgrounds/
garageband
amplitube http://www.ikmultimedia.com/products/amplitubeios/
Djay pro https://www.algoriddim.com/djay-pro-ipad
frame.io https://www.frame.io/
ulysses http://www.ulyssesapp.com/
Auxy http://auxy.co/
There are a bunch of others but those are my favorites/ones I've used in the past. I've been able to create full game prototypes all on my iPad. In fact the next game jam I do may just use my iPad. Pair it with a dropbox account and fast internet and I can handle almost anything a computer can, though admittedly it's limited in a lot of cases. Still can't do full releasable app builds on device for example.
No. Because it's not relevant to working with code in swift playgrounds on an iPad. It's not even relevant to working with XCode and hasn't been for some time now. I'd never say XCode 'just works', but it currently works better than it did. Especially around provisioning and most especially around just getting some code to run on a device. I well remember that WTAF moment when I plugged my first iPhone into my first mac and realised that just to run hello world I would need to give Apple money and then do those things that you said. Doesn't work like that anymore.
Edit: fat fingers
If you put it that way, it's impossible to write any code and run it on any device without paying something to some company.
These things work out expensive!
It's a mess and I don't see why it has to be so complicated for development.
So basically the external tool don't properly set the 'development team' variable in the generated Xcode project.
May I ask how this is supposed to be Apple's fault if a third party App haven't yet been updated to meet new requirements? Did you update XCode ahead of version supported by your external tool?
Coming from scripting languages, I'm starting to learn pure Xcode/Cocoa/Swift workflow with a free account and I really don't relate to problems you are describing (but my target is only macOs for now, so I might miss the deployement hassle you describe I give you that)
For instance, you also cannot distribute Xcode project files now which simply compile out of the box. You'll have to go into project settings first and set the development team for every single app target.
Why the development team is part of the project setting, and not simply an Xcode-wide setting in the preferences is beyond me.
Sorry buddy, this build is from last Wednesday, so all it can do is launch itself and immediately crash back to home screen.
Sure, an anecdote. But my experience with XCode and provisioning so far is that I stumble on different, unexpected weirdnesses like these, over and over again.
For these learning environments it would be pretty awesome if there was a simple way to share the actual app. At least it seems they make it easy to share the code and a video which is a decent start.
Yeah, it's so difficult that App Store only has about 1.5 million apps -- merely the largest in the world...
Either those belong to a REALLY determined million of devs, or it's not that hard really...
Here is a report of someone using that book to get started, https://hackernoon.com/i-develop-therefore-i-am-b501e2a10277...
I occasionally teach blind kids programming. Sometimes it takes an hour to just navigate them through an unfamiliar setup with a screen reader. If this can be used by a blind person, it could be a game changer.
> [Jordyn Castor] was a driving force behind accessibility on Apple's soon-to-be released Swift Playgrounds, an intro-to-coding program geared toward children. She's been working to make the program accessible to blind children, who have been waiting a long time for the tool, she says.
Hopefully will come as part of a later update. It is such a great opportunity for Apple.
Edit: Why the downvote? I still have an iPad mini (1st gen), and I don't get to play with Swift Playground because iOS 10 requires iPad mini 2 or newer. Look, I'm as much an Apple fanboy as the next person: I use a MacBook Pro, I have an iPhone 6s Plus, and my wife will be getting an iPhone 7 Plus, but you can't deny that Apple, just like other companies, build arbitrary obsolescence into their products.
They're completely different machines in practice.
If they allow an iOS version to be compatible with an under powered device that can barely run it they'll get criticized for slowing down older machines or even accused of deliberately crippling them down to force upgrades.
If they don't allow new iOS versions to run on older machines with lower specs, they get accused of deliberately deprecating older models to force upgrades.
(And furthermore the 3-year-old iPad mini 2 is probably stretching the definition of "shiny new"...)
https://www.youtube.com/watch?v=CAcv12eBqcc
Another sample: use Xcode on iPad for publish to AppStore remotely.
http://acpul.tumblr.com/image/116464494150
Coming soon...
I've seen dozens of attempts but they all seem to fizzle pretty quickly.
Indeed, that's a shame, what better example than open sourcing the tool used to teach the language...
Apple doesn't have unlimited people to assign to this project. They chose a platform where they can focus on providing the best experience for. Why complain?